Usenet 1993 July/InfoMagic USENET CD-ROM July 1993.ISO/sources/misc/volume15/dmake-3.6/part15

Text File | 1990-10-14 | 39.5 KB | 1,058 lines

Newsgroups: comp.sources.misc
X-UNIX-From: [e-mail]
subject: v15i067: dmake version 3.6 (part 15/25)
from: Dennis Vadura <[e-mail]>
Sender: [e-mail] (Brandon S. Allbery - comp.sources.misc)

Posting-number: Volume 15, Issue 67
Submitted-by: Dennis Vadura <[e-mail]>
Archive-name: dmake-3.6/part15

#!/bin/sh
# this is part 15 of a multipart archive
# do not concatenate these parts, unpack them in order with /bin/sh
# file man/dmake.p continued
#
CurArch=15
if test ! -r s2_seq_.tmp
then echo "Please unpack part 1 first!"
     exit 1; fi
( read Scheck
  if test "$Scheck" != $CurArch
  then echo "Please unpack part $Scheck next!"
       exit 1;
  else exit 0; fi
) < s2_seq_.tmp || exit 1
echo "x - Continuing file man/dmake.p"
sed 's/^X//' << 'SHAR_EOF' >> man/dmake.p
X     a target having the .LIBMEMBER (library member) attribute is
X     searched for, it is first searched for as an ordinary file.
X     When a number of library members require updating it is
X     desirable to compile all of them first and to update the
X     library at the end in a single operation.  If one of the
X     members does not compile and ddmmaakkee stops, then the user may
X     fix the error and make again.  ddmmaakkee will not remake any of
X     the targets whose object files have already been generated
X     as long as none of their prerequisite files have been modi-
X     fied as a result of the fix.
X
X     When defining .SOURCE and .SOURCE.x targets the construct
X
X
X
X
XVersion 3.50                    UW                             30
X
X
X
X
XDMAKE(p)               Unsupported Software               DMAKE(p)
X
X
X
X          .SOURCE :
X          .SOURCE : fred gery
X
X     is equivalent to
X
X          .SOURCE :- fred gery
X
X     ddmmaakkee correctly handles the UNIX Make variable VPATH.  By
X     definition VPATH contains a list of ':' separated direc-
X     tories to search when looking for a target.  ddmmaakkee maps
X     VPATH to the following special rule:
X
X          .SOURCE :^ $(VPATH:s/:/ /)
X
X     Which takes the value of VPATH and sets .SOURCE to the same
X     set of directories as specified in VPATH.
X
XPPEERRCCEENNTT((%%)) RRUULLEESS AANNDD MMAAKKIINNGG IINNFFEERREENNCCEESS
X     When ddmmaakkee makes a target it's set of prerequisites (if any)
X     must exist and the target must have a recipe which ddmmaakkee can
X     use to make it.  If the makefile does not specify an expli-
X     cit recipe for the target then ddmmaakkee uses special rules to
X     try to infer a recipe which it can use to make the target.
X     Previous versions of Make perform this task by using rules
X     that are defined by targets of the form .<suffix>.<suffix>
X     and by using the .SUFFIXES list of suffixes.  The exact
X     workings of this mechanism were sometimes difficult to
X     understand and often limiting in their usefulness.  Instead,
X     ddmmaakkee supports the concept of _%_-_m_e_t_a rules. The syntax and
X     semantics of these rules differ from standard rule lines as
X     follows:
X
X          _<_%_-_t_a_r_g_e_t_> [_<_a_t_t_r_i_b_u_t_e_s_>] _<_r_u_l_e_o_p_> [_<_%_-_p_r_e_r_e_q_u_i_s_i_t_e_s_>] [;_<_r_e_c_i_p_e_>]
X
X     where _%_-_t_a_r_g_e_t is a target containing exactly a single `%'
X     sign, _a_t_t_r_i_b_u_t_e_s is a list (possibly empty) of attributes,
X     _r_u_l_e_o_p is the standard set of rule operators, _%_-_p_r_e_r_e_-
X     _q_u_i_s_i_t_e_s , if present, is a list of prerequisites containing
X     zero or more `%' signs, and _r_e_c_i_p_e_, if present, is the first
X     line of the recipe.
X
X     The _%_-_t_a_r_g_e_t defines a pattern against which a target whose
X     recipe is being inferred gets matched.  The pattern match
X     goes as follows:  all chars are matched exactly from left to
X     right up to but not including the % sign in the pattern, %
X     then matches the longest string from the actual target name
X     not ending in the suffix given after the % sign in the pat-
X     tern.  Consider the following examples:
X
X          %.c       matches fred.c but not joe.c.Z
X          dir/%.c   matches dir/fred.c but not dd/fred.c
X          fred/%    matches fred/joe.c but not f/joe.c
X
X
X
XVersion 3.50                    UW                             31
X
X
X
X
XDMAKE(p)               Unsupported Software               DMAKE(p)
X
X
X
X          %         matches anything
X
X     In each case the part of the target name that matched the %
X     sign is retained and is substituted for any % signs in the
X     prerequisite list of the %-meta rule when the rule is
X     selected during inference and ddmmaakkee constructs the depen-
X     dency specified by the %-meta rule for the actual target.
X     As an example the following %-meta rules describe the fol-
X     lowing:
X
X          %.c : %.y ; recipe...
X
X     describes how to make any file ending in .c if a correspond-
X     ing file ending in .y can be found.
X
X          foo%.o : fee%.k ; recipe...
X
X     is used to describe how to make fooxxxx.o from feexxxx.k.
X
X          %.a :; recipe...
X
X     describes how to make a file whose suffix is .a without
X     inferring any prerequisites.
X
X          %.c : %.y yaccsrc/%.y ; recipe...
X
X     is a short form for the construct:
X
X          %.c : %.y ; recipe...
X          %.c : yaccsrc/%.y ; recipe...
X
X     ie. It is possible to specify the same recipe for two
X     %-rules by giving more than one prerequisite in the prere-
X     quisite list.  A more interesting example is:
X
X          % : RCS/%,v ; co $@
X
X     which describes how to take any target and check it out of
X     the RCS directory if the corresponding file exists in the
X     RCS directory.  The equivalent SCCS rule would be:
X
X          % : s.% ; get $@
X
X
X     The previous RCS example defines an infinite rule, because
X     it says how to make _a_n_y_t_h_i_n_g from RCS/%,v, and _a_n_y_t_h_i_n_g also
X     includes RCS/fred.c,v.  To limit the size of the graph that
X     results from such rules ddmmaakkee uses the macro variable PREP
X     (stands for % repetition).  By default the value of this
X     variable is 0, which says that no repetitions of a %-rule
X     are to be generated.  If it is set to something greater than
X     0, then that many repetitions of any infinite %-rule are
X
X
X
XVersion 3.50                    UW                             32
X
X
X
X
XDMAKE(p)               Unsupported Software               DMAKE(p)
X
X
X
X     allowed.  If in the above example PREP was set to 1, then
X     ddmmaakkee would generate the dependency graph:
X
X          % --> RCS/%,v --> RCS/RCS/%,v,v
X
X     Where each link is assigned the same recipe as the first
X     link.  PREP should be used only in special cases, since it
X     may result in a large increase in the number of possible
X     prerequisites tested.
X
X     ddmmaakkee supports dynamic prerequisite generation for prere-
X     quisites of %-meta rules.  This is best illustrated by an
X     example.  The RCS rule shown above can infer how to check
X     out a file from a corresponding RCS file only if the target
X     is a simple file name with no directory information.  That
X     is, the above rule can infer how to find _R_C_S_/_f_r_e_d_._c_,_v from
X     the target _f_r_e_d_._c, but cannot infer how to find
X     _s_r_c_d_i_r_/_R_C_S_/_f_r_e_d_._c_,_v from _s_r_c_d_i_r_/_f_r_e_d_._c because the above
X     rule will cause ddmmaakkee to look for RCS/srcdir/fred.c,v; which
X     does not exist (assume that srcdir has it's own RCS direc-
X     tory as is the common case).
X
X     A more versatile formulation of the above RCS check out rule
X     is the following:
X
X          % :  $$(@:d)RCS/$$(@:f),v : co $@
X
X     This rule uses the dynamic macro $@ to specify the prere-
X     quisite to try to infer.  During inference of this rule the
X     macro $@ is set to the value of the target of the %-meta
X     rule and the appropriate prerequisite is generated by
X     extracting the directory portion of the target name (if
X     any), appending the string _R_C_S_/ to it, and appending the
X     target file name with a trailing _,_v attached to the previous
X     result.
X
X     ddmmaakkee can also infer indirect prerequisites.  An inferred
X     target can have a list of prerequisites added that will not
X     show up in the value of $< but will show up in the value of
X     $? and $&.  Indirect prerequisites are specified in an
X     inference rule by quoting the prerequisite with single
X     quotes.  For example, if you had the explicit dependency:
X
X          fred.o : fred.c ; rule to make fred.o
X          fred.o : local.h
X
X     then this can be infered for fred.o from the following
X     inference rule:
X
X          %.o : %.c 'local.h' ; rule to make a .o from a .c
X
X     You may infer indirect prerequisites that are a function of
X
X
X
XVersion 3.50                    UW                             33
X
X
X
X
XDMAKE(p)               Unsupported Software               DMAKE(p)
X
X
X
X     the value of '%' in the current rule.  The meta-rule:
X
X          %.o : %.c '$(INC)/%.h' ; rule to make a .o from a .c
X
X     infers an indirect prerequisite found in the INC directory
X     whose name is the same as the expansion of $(INC), and the
X     prerequisite name depends on the base name of the current
X     target.  The set of indirect prerequisites is attached to
X     the meta rule in which they are specified and are inferred
X     only if the rule is used to infer a recipe for a target.
X     They do not play an active role in driving the inference
X     algorithm.  The construct:
X
X          %.o : %.c %.f 'local.h'; recipe
X
X     is equivalent to:
X
X          %.o : %.c 'local.h' : recipe
X          %.o : %.f 'local.h' : recipe
X
X
X     If any of the attributes .SETDIR, .EPILOG, .PROLOG, .SILENT,
X     .USESHELL, .SWAP, .PRECIOUS, .LIBRARY, and .IGNORE are given
X     for a %-rule then when that rule is bound to a target as the
X     result of an inference, the target's set of attributes is
X     augmented by the attributes from the above set that are
X     specified in the bound %-rule.  Other attributes specified
X     for %-meta rules are not inherited by the target.  The .SET-
X     DIR attribute is treated in a special way.  If the target
X     already had a .SETDIR attribute set and the bound %-rule
X     also specified a .SETDIR attribute then the one originally
X     specified with the target prevails.  During inference any
X     .SETDIR attributes for the inferred prerequisite are
X     honored.  The directories must exist for a %-meta rule to be
X     selected as a possible inference path.  If the directories
X     do not exist no error message is issued, instead the
X     corresponding path in the inference graph is simply
X     rejected.
X
X     ddmmaakkee also supports the old format special target
X     .<suffix>.<suffix> by identifying any rules of this form and
X     mapping them to the appropriate %-rule.  So for example if
X     an old makefile contains the construct:
X
X          .c.o :; cc -c $< -o $@
X
X     ddmmaakkee maps this into the following %-rule:
X
X          %.o : %.c; cc -c $< -o $@
X
X     Furthermore, ddmmaakkee understands several SYSV AUGMAKE special
X     targets and maps them into corresponding %-meta rules.
X
X
X
XVersion 3.50                    UW                             34
X
X
X
X
XDMAKE(p)               Unsupported Software               DMAKE(p)
X
X
X
X     These transformation must be enabled by providing the -A
X     flag on the command line or by setting the value of AUGMAKE
X     to non NULL.  The construct
X
X          .suff :; recipe
X
X     gets mapped into:
X
X          % : %.suff; recipe
X
X     and the construct
X
X          .c~.o :; recipe
X
X     gets mapped into:
X
X          %.o : s.%.c ; recipe
X
X     In general, a special target of the form .<str>~ is replaced
X     by the %-rule construct s.%.<str>, thereby providing support
X     for the syntax used by SYSV AUGMAKE for providing SCCS sup-
X     port.  When enabled, these mappings allow processing of
X     existing SYSV makefiles without modifications.
X
X     ddmmaakkee bases all of it's inferences on the inference graph
X     constructed from the %-rules defined in the makefile.  It
X     knows exactly which targets can be made from which prere-
X     quisites by making queries on the inference graph.  For this
X     reason .SUFFIXES is not needed and is completely ignored.
X
X     For a %-meta rule to be inferred as the rule whose recipe
X     will be used to make a target, the target's name must match
X     the %-target pattern, and any inferred %-prerequisite must
X     already exist or have an explicit recipe so that the prere-
X     quisite can be made.  Without _t_r_a_n_s_i_t_i_v_e _c_l_o_s_u_r_e on the
X     inference graph the above rule describes precisely when an
X     inference match terminates the search.  If transitive clo-
X     sure is enabled (the usual case), and a prerequisite does
X     not exist or cannot be made, then ddmmaakkee invokes the infer-
X     ence algorithm recursively on the prerequisite to see if
X     there is some way the prerequisite can be manufactured.  For
X     if the prerequisite can be made then the current target can
X     also be made using the current %-meta rule.  This means that
X     there is no longer a need to give a rule for making a .o
X     from a .y if you have already given a rule for making a .o
X     from a .c and a .c from a .y.  In such cases ddmmaakkee can infer
X     how to make the .o from the .y via the intermediary .c and
X     will remove the .c when the .o is made.  Transitive closure
X     can be disabled by giving the -T switch on the command line.
X
X     A word of caution.  ddmmaakkee bases its transitive closure on
X     the %-meta rule targets.  When it performs transitive
X
X
X
XVersion 3.50                    UW                             35
X
X
X
X
XDMAKE(p)               Unsupported Software               DMAKE(p)
X
X
X
X     closure it infers how to make a target from a prerequisite
X     by performing a pattern match as if the potential prere-
X     quisite were a new target.  The set of rules:
X
X          %.o : %.c :; rule for making .o from .c
X          %.c : %.y :; rule for making .c from .y
X          % : RCS/%,v :; check out of RCS file
X
X     will, by performing transitive closure, allow ddmmaakkee to infer
X     how to make a .o from a .y using a .c as an intermediate
X     temporary file.  Additionally it will be able to infer how
X     to make a .y from an RCS file, as long as that RCS file is
X     in the RCS directory and has a name which ends in .y,v.  The
X     transitivity computation is performed dynamically for each
X     target that does not have a recipe.  This has potential to
X     be very slow if the %-meta rules are not carefully speci-
X     fied.  The .NOINFER attribute is used to mark a %-meta node
X     as being a final target during inference.  Any node with
X     this attribute set will not be used for subsequent infer-
X     ences.  As an example the node RCS/%,v is marked as a final
X     node since we know that if the RCS file does not exist there
X     likely is no other way to make it.  Thus the standard
X     startup makefile contains the entry:
X          .NOINFER : RCS/%,v
X     Thereby indicating that the RCS file is the end of the
X     inference chain.
X
X     ddmmaakkee tries to remove intermediate files resulting from
X     transitive closure if the file is not marked as being PRE-
X     CIOUS, or the --uu flag was not given on the command line, and
X     if the inferred intermediate did not previously exist.
X     Intermediate targets that existed prior to being made are
X     never removed.  This is in keeping with the philosophy that
X     ddmmaakkee should never remove things from the file system that
X     it did not add.  If the special target .REMOVE is defined
X     and has a recipe then ddmmaakkee constructs a list of the inter-
X     mediate files to be removed and makes them prerequisites of
X     .REMOVE.  It then makes .REMOVE thereby removing the prere-
X     quisites if the recipe of .REMOVE says to.  Typically
X     .REMOVE is defined in the startup file as:
X
X          ".REMOVE :; $(RM) $<".
X
XMMAAKKIINNGG TTAARRGGEETTSS
X     In order to update a target ddmmaakkee must execute a recipe.
X     When a recipe needs to be executed it is first expanded so
X     that any macros in the recipe text are expanded, and it is
X     then either executed directly or passed to a shell.  ddmmaakkee
X     supports two types of recipes.  The regular recipes and
X     group recipes.
X
X
X
X
X
XVersion 3.50                    UW                             36
X
X
X
X
XDMAKE(p)               Unsupported Software               DMAKE(p)
X
X
X
X     When a regular recipe is invoked ddmmaakkee executes each line of
X     the recipe separately using a new copy of a shell if a shell
X     is required.  Thus effects of commands do not generally per-
X     sist across recipe lines.  (e.g. cd requests in a recipe
X     line do not carry over to the next recipe line) The decision
X     on whether a shell is required to execute a command is based
X     on the value of the macro SHELLMETAS or on the specification
X     of '+' or .USESHELL for the current recipe or target respec-
X     tively.  If any character in the value of SHELLMETAS is
X     found in the expanded recipe text-line or the use of a shell
X     is requested explicitly via '+' or .USESHELL then the com-
X     mand is executed using a shell, otherwise the command is
X     executed directly.  The shell that is used for execution is
X     given by the value of the macro SHELL.  The flags that are
X     passed to the shell are given by the value of SHELLFLAGS.
X     Thus ddmmaakkee constructs the command line:
X
X          $(SHELL) $(SHELLFLAGS) $(expanded_recipe_command)
X
X     Normally ddmmaakkee writes the command line that it is about to
X     invoke to standard output.  If the .SILENT attribute is set
X     for the target or for the recipe line (via @), then the
X     recipe line is not echoed.
X
X     Group recipe processing is similar to that of regular
X     recipes, except that a shell is always invoked.  The shell
X     that is invoked is given by the value of the macro GROUP-
X     SHELL, and its flags are taken from the value of the macro
X     GROUPFLAGS.  If a target has the .PROLOG attribute set then
X     ddmmaakkee prepends to the shell script the recipe associated
X     with the special target .GROUPPROLOG, and if the attribute
X     .EPILOG is set as well, then the recipe associated with the
X     special target .GROUPEPILOG is appended to the script file.
X     This facility can be used to always prepend a common header
X     and common trailer to group recipes.  Group recipes are
X     echoed to standard output just like standard recipes, but
X     are enclosed by lines beginning with [ and ].
X
XMMAAKKIINNGG LLIIBBRRAARRIIEESS
X     Libraries are easy to maintain using ddmmaakkee.  A library is a
X     file containing a collection of object files.  Thus to make
X     a library you simply specify it as a target with the
X     .LIBRARY attribute set and specify its list of prere-
X     quisites.  The prerequisites should be the object members
X     that are to go into the library.  When ddmmaakkee makes the
X     library target it uses the .LIBRARY attribute to pass to the
X     prerequisites the .LIBMEMBER attribute and the name of the
X     library.  This enables the file binding mechanism to look
X     for the member in the library if an appropriate object file
X     cannot be found. A small example best illustrates this.
X
X          mylib.a .LIBRARY : mem1.o mem2.o mem3.o
X
X
X
XVersion 3.50                    UW                             37
X
X
X
X
XDMAKE(p)               Unsupported Software               DMAKE(p)
X
X
X
X               rules for making library...
X               # remember to remove .o's when lib is made
X
X          # equivalent to:  '%.o : %.c ; ...'
X          .c.o :; rules for making .o from .c say
X
X     ddmmaakkee will use the .c.o rule for making the library members
X     if appropriate .c files can be found using the search rules.
X     NOTE:  this is not specific in any way to C programs, they
X     are simply used as an example.
X
X     ddmmaakkee tries to handle the old library construct format in a
X     sensible way.  The construct _l_i_b_(_m_e_m_b_e_r_._o_) is separated and
X     the _l_i_b portion is declared as a library target.  The new
X     target is defined with the .LIBRARY attribute set and the
X     _m_e_m_b_e_r_._o portion of the construct is declared as a prere-
X     quisite of the lib target.  If the construct _l_i_b_(_m_e_m_b_e_r_._o_)
X     appears as a prerequisite of a target in the makefile, that
X     target has the new name of the lib assigned as it's prere-
X     quisite.  Thus the following example:
X
X          a.out : ml.a(a.o) ml.a(b.o); $(CC) -o $@  $<
X
X          .c.o :; $(CC) -c $(CFLAGS) -o $@  $<
X          %.a:
X               ar rv $@ $<
X               ranlib $@
X               rm -rf $<
X
X     constructs the following dependency graph.
X
X          a.out : ml.a; $(CC) -o $@  $<
X          ml.a .LIBRARY : a.o b.o
X
X          %.o : %.c ; $(CC) -c $(CFLAGS) -o $@  $<
X          %.a :
X               ar rv $@ $<
X               ranlib $@
X               rm -rf $<
X
X     and making a.out then works as expected.
X
X     The same thing happens for any target of the form
X     _l_i_b_(_(_e_n_t_r_y_)_).  These targets have an additional feature in
X     that the _e_n_t_r_y target has the .SYMBOL attribute set automat-
X     ically.
X
X     NOTE:  If the notion of entry points is supported by the
X     archive and by ddmmaakkee (currently not the case) then ddmmaakkee
X     will search the archive for the entry point and return not
X     only the modification time of the member which defines the
X     entry but also the name of the member file.  This name will
X
X
X
XVersion 3.50                    UW                             38
X
X
X
X
XDMAKE(p)               Unsupported Software               DMAKE(p)
X
X
X
X     then replace _e_n_t_r_y and will be used for making the member
X     file.  Once bound to an archive member the .SYMBOL attribute
X     is removed from the target.  This feature is presently dis-
X     abled as there is little standardization among archive for-
X     mats, and we have yet to find a makefile utilizing this
X     feature (possibly due to the fact that it is unimplemented
X     in most versions of UNIX Make).
X
XMMUULLTTII PPRROOCCEESSSSIINNGG
X     If the architecture supports it then ddmmaakkee is capable of
X     making a target's prerequisites in parallel.  ddmmaakkee will
X     make as much in parallel as it can and use a number of child
X     processes up to the maximum specified by MAXPROCESS or by
X     the value supplied to the -P command line flag.  A parallel
X     make is enabled by setting the value of MAXPROCESS (either
X     directly or via -P option) to a value which is > 1.  ddmmaakkee
X     guarantees that all dependencies as specified in the
X     makefile are honored.  A target will not be made until all
X     of its prerequisites have been made.  If a parallel make is
X     being performed then the following restrictions on parallel-
X     ism are enforced.
X
X          1.   Individual recipe lines in a non-group recipe are
X               performed sequentially in the order in which they
X               are specified within the makefile and in parallel
X               with the recipes of other targets.
X
X          2.   If a target contains multiple recipe definitions
X               (cf. :: rules) then these are performed sequen-
X               tially in the order in which the :: rules are
X               specified within the makefile and in parallel with
X               the recipes of other targets.
X
X          3.   If a target rule contains the `!' modifier, then
X               the recipe is performed sequentially for the list
X               of outdated prerequisites and in parallel with the
X               recipes of other targets.
X
X          4.   If a target has the .SEQUENTIAL attribute set then
X               all of its prerequisites are made sequentially
X               relative to one another (as if MAXPROCESS=1), but
X               in parallel with other targets in the makefile.
X
X     Note:  If you specify a parallel make then the order of tar-
X     get update and the order in which the associated recipes are
X     invoked will not correspond to that displayed by the -n
X     flag.
X
XCCOONNDDIITTIIOONNAALLSS
X     ddmmaakkee supports a makefile construct called a _c_o_n_d_i_t_i_o_n_a_l.
X     It allows the user to conditionally select portions of
X     makefile text for input processing and to discard other
X
X
X
XVersion 3.50                    UW                             39
X
X
X
X
XDMAKE(p)               Unsupported Software               DMAKE(p)
X
X
X
X     portions.  This becomes useful for writing makefiles that
X     are intended to function for more than one target host and
X     environment.  The conditional expression is specified as
X     follows:
X
X          .IF  _e_x_p_r_e_s_s_i_o_n
X             ... if text ...
X          .ELSE
X             ... else text ...
X          .END
X
X     The .ELSE portion is optional, and the conditionals may be
X     nested (ie.  the text may contain another conditional).
X     .IF, .ELSE, and .END may appear anywhere in the makefile,
X     but a single conditional expression may not span multiple
X     makefiles.
X
X     _e_x_p_r_e_s_s_i_o_n can be one of the following three forms:
X
X          <text> | <text> == <text> | <text> != <text>
X
X     where _t_e_x_t is either text or a macro expression.  In any
X     case, before the comparison is made, the expression is
X     expanded.  The text portions are then selected and compared.
X     White space at the start and end of the text portion is dis-
X     carded before the comparison.  This means that a macro that
X     evaluates to nothing but white space is considered a NULL
X     value for the purpose of the comparison.  In the first case
X     the expression evaluates TRUE if the text is not NULL other-
X     wise it evaluates FALSE.  The remaining two cases both
X     evaluate the expression on the basis of a string comparison.
X     If a macro expression needs to be equated to a NULL string
X     then compare it to the value of the macro $(NULL).
X
XEEXXAAMMPPLLEESS
X          # A simple example showing how to use make
X          #
X          prgm : a.o b.o
X               cc a.o b.o -o prgm
X          a.o : a.c g.h
X               cc a.c -o $@
X          b.o : b.c g.h
X               cc b.c -o $@
X
X     In the previous example prgm is remade only if a.o and/or
X     b.o is out of date with respect to prgm.  These dependencies
X     can be stated more concisely by using the inference rules
X     defined in the standard startup file.  The default rule for
X     making .o's from .c's looks something like this:
X
X          %.o : %.c; cc -c $(CFLAGS) -o $@ $<
X
X
X
X
XVersion 3.50                    UW                             40
X
X
X
X
XDMAKE(p)               Unsupported Software               DMAKE(p)
X
X
X
X     Since there exists a rule (defined in the startup file) for
X     making .o's from .c's ddmmaakkee will use that rule for manufac-
X     turing a .o from a .c and we can specify our dependencies
X     more concisely.
X
X          prgm : a.o b.o
X               cc -o prgm $<
X          a.o b.o : g.h
X
X     A more general way to say the above using the new macro
X     expansions would be:
X
X          SRC = a b
X          OBJ = {$(SRC)}.o
X
X          prgm : $(OBJ)
X               cc -o $@ $<
X
X          $(OBJ) : g.h
X
X     If we want to keep the objects in a separate directory,
X     called objdir, then we would write something like this.
X
X          SRC = a b
X          OBJ = {$(SRC)}.o
X
X          prgm : $(OBJ)
X               cc $< -o $@
X
X          $(OBJ) : g.h
X          %.o : %.c
X               $(CC) -c $(CFLAGS) -o $(@:f) $<
X               mv $(@:f) objdir
X
X          .SOURCE.o : objdir       # tell make to look here for .o's
X
X     An example of building library members would go something
X     like this: (NOTE:  The same rules as above will be used to
X     produce .o's from .c's)
X
X          SRC  = a b
X          LIB  = lib
X          LIBm = { $(SRC) }.o
X
X          prgm: $(LIB)
X               cc -o $@ $(LIB)
X
X          $(LIB) .LIBRARY : $(LIBm)
X               ar rv $@ $<
X               rm $<
X
X     Finally, suppose that each of the source files in the
X
X
X
XVersion 3.50                    UW                             41
X
X
X
X
XDMAKE(p)               Unsupported Software               DMAKE(p)
X
X
X
X     previous example had the `:' character in their target name.
X     Then we would write the above example as:
X
X          SRC  = f:a f:b
X          LIB  = lib
X          LIBm = "{ $(SRC) }.o"         # put quotes around each token
X
X          prgm: $(LIB)
X               cc -o $@ $(LIB)
X
X          $(LIB) .LIBRARY : $(LIBm)
X               ar rv $@ $<
X               rm $<
X
XCCOOMMPPAATTIIBBIILLIITTYY
X     There are two notable differences between ddmmaakkee and the
X     standard version of BSD UNIX 4.2/4.3 Make.
X
X          1. BSD UNIX 4.2/4.3 Make supports wild card filename
X             expansion for prerequisite names.  Thus if a direc-
X             tory contains a.h, b.h and c.h, then a line like
X
X                  target: *.h
X
X             will cause UNIX make to expand the *.h into "a.h b.h
X             c.h".  ddmmaakkee does not support this type of filename
X             expansion.
X
X          2. Unlike UNIX make, touching a library member causes
X             ddmmaakkee to search the library for the member name and
X             to update the library time stamp.  This is only
X             implemented in the UNIX version.  MSDOS and other
X             versions may not have librarians that keep file time
X             stamps, as a result ddmmaakkee touches the library file
X             itself, and prints a warning.
X
X     ddmmaakkee is not compatible with GNU Make.  In particular it
X     does not understand GNU Make's macro expansions that query
X     the file system.
X
X     ddmmaakkee is fully compatible with SYSV AUGMAKE, and supports
X     the following AUGMAKE features:
X
X          1. The word iinncclluuddee appearing at the start of a line
X             can be used instead of the ".INCLUDE :" construct
X             understood by ddmmaakkee.
X
X          2. The macro modifier expression $(macro:str=sub) is
X             understood and is equivalent to the expression
X             $(macro:s/str/sub), with the restriction that str
X             must match the following regular expression:
X
X
X
X
XVersion 3.50                    UW                             42
X
X
X
X
XDMAKE(p)               Unsupported Software               DMAKE(p)
X
X
X
X                  str[ |\t][ |\t]*
X
X             (ie. str only matches at the end of a token where
X             str is a suffix and is terminated by a space, a tab,
X             or end of line)
X
X          3. The macro % is defined to be $@ (ie. $% expands to
X             the same value as $@).
X
X          4. The AUGMAKE notion of libraries is handled
X             correctly.
X
X          5. When defining special targets for the inference
X             rules and the AUGMAKE special target mapping is
X             enabled then the special target .X is equivalent to
X             the %-rule "% : %.X".
X
XLLIIMMIITTSS
X     In some environments the length of an argument string is
X     restricted.  (e.g. MSDOS command line arguments cannot be
X     longer than 128 bytes if you are using the standard
X     command.com command interpreter as your shell, ddmmaakkee text
X     diversions may help in these situations.)
X
XPPOORRTTAABBIILLIITTYY
X     To write makefiles that can be moved from one environment to
X     another requires some forethought.  In particular you must
X     define as macros all those things that may be different in
X     the new environment.  ddmmaakkee has two facilities that help to
X     support writing portable makefiles, recursive macros and
X     conditional expressions.  The recursive macros, allow one to
X     define environment configurations that allow different
X     environments for similar types of operating systems.  For
X     example the same make script can be used for SYSV and BSD
X     but with different macro definitions.
X
X     To write a makefile that is portable between UNIX and MSDOS
X     requires both features since in almost all cases you will
X     need to define new recipes for making targets.  The recipes
X     will probably be quite different since the capabilities of
X     the tools on each machine are different.  Different macros
X     will be needed to help handle the smaller differences in the
X     two environments.
X
X     NOTE:  Unlike UNIX, MSDOS ddooeess maintain cd requests cross
X     single recipe lines.  This is not portable, and your
X     makefiles will not work the same way if you depend on it.
X     Use the .IF ... .ELSE ... .END conditionals to supply dif-
X     ferent make scripts as necessary.
X
X
X
X
X
X
XVersion 3.50                    UW                             43
X
X
X
X
XDMAKE(p)               Unsupported Software               DMAKE(p)
X
X
X
XFFIILLEESS
X     Makefile, makefile, startup.mk (use dmake -V to tell you
X     where the startup file is)
X
XSSEEEE AALLSSOO
X     sh(1), csh(1), touch(1), f77(1), pc(1), cc(1)
X     S.I. Feldman  _M_a_k_e _- _A _P_r_o_g_r_a_m _f_o_r _M_a_i_n_t_a_i_n_i_n_g _C_o_m_p_u_t_e_r _P_r_o_-
X     _g_r_a_m_s
X
XAAUUTTHHOORR
X     Dennis Vadura, CS Dept. University of Waterloo.
X     [e-mail]
X     Many thanks to Carl Seger for his helpful suggestions, and
X     to Trevor John Thompson for his many excellent ideas and
X     informative bug reports.
X
XBBUUGGSS
X     Some system commands return non-zero status inappropriately.
X     Use --ii (`-' within the makefile) to overcome the difficulty.
X
X     Some systems do not have easily accessible time stamps for
X     library members (MSDOS, AMIGA, etc) for these ddmmaakkee uses the
X     time stamp of the library instead and prints a warning the
X     first time it does so.  This is almost always ok, except
X     when multiple makefiles update a single library file.  In
X     these instances it is possible to miss an update if one is
X     not careful.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
XVersion 3.50                    UW                             44
SHAR_EOF
echo "File man/dmake.p is complete"
chmod 0640 man/dmake.p || echo "restore of man/dmake.p fails"
echo "x - extracting man/dmake.nc (Text)"
sed 's/^X//' << 'SHAR_EOF' > man/dmake.nc &&
X
X
X
X
XDMAKE(p)               Unsupported Software               DMAKE(p)
X
X
X
XNAME
X     dmake - maintain program groups, or interdependent files
X
XSYNOPSIS
X     dmake [-AeEhiknpqersStTuvVx] [-P#] [macro[*][+][:]=value]
X     [-f file] [target ...]
X
XDESCRIPTION
X     dmake executes commands found in an external file called a
X     makefile to update one or more target names.  Each target
X     may depend on zero or more prerequisite targets.  If any of
X     the target's prerequisites is newer than the target or if
X     the target itself does not exist, then dmake will attempt to
X     make the target.
X
X     If no -f command line option is present then dmake searches
X     for an existing makefile from the list of prerequisites
X     specified for the special target .MAKEFILES (see the STARTUP
X     section for more details).  If "-" is the name of the file
X     specified to the -f flag then dmake uses standard input as
X     the source of the makefile text.
X
X     Any macro definitions (arguments with embedded "=" signs)
X     that appear on the command line are processed first and
X     supercede definitions for macros of the same name found
X     within the makefile.  In general it is impossible for defin-
X     itions found inside the makefile to redefine a macro defined
X     on the command line, see the MACROS section for an excep-
X     tion.
X
X     If no target names are specified on the command line, then
X     dmake uses the first non-special target found in the
X     makefile as the default target.  See the SPECIAL TARGETS
X     section for the list of special targets and their function.
X     dmake is a re-implementation of the UNIX Make utility with
X     significant enhancements.  Makefiles written for most previ-
X     ous versions of make will be handled correctly by dmake.
X     Known differences between dmake and other versions of make
X     are discussed in the COMPATIBILITY section found at the end
X     of this document.
X
XOPTIONS
X     -A   Enable AUGMAKE special inference rule transformations
X          (see the "PERCENT(%) RULES" section), these are set to
X          off by default.
X
X     -e   Read the environment and define all strings of the form
X          'ENV-VAR=evalue' defined within as macros whose name is
X          ENV-VAR, and whose value is 'evalue'.  The environment
X          is processed prior to processing the user specified
X          makefile thereby allowing definitions in the makefile
X          to override definitions in the environment.
X
X
X
XVersion 3.50                    UW                              1
X
X
X
X
XDMAKE(p)               Unsupported Software               DMAKE(p)
X
X
X
X     -E   Same as -e, except that the environment is processed
X          after the user specified makefile has been processed
X          (thus definitions in the environment override defini-
X          tions in the makefile).  The -e and -E options are
X          mutually exclusive.  If both are given the latter one
X          takes effect.
X
X     -f file
X          Use file as the source for the makefile text.  Only one
X          -f option is allowed.
X
X     -h   Print the command summary for dmake.
X
X     -i   Tells dmake to ignore errors, and continue making other
X          targets.  This is equivalent to the .IGNORE attribute
X          or macro.
X
X     -k   Causes dmake to ignore errors caused by command execu-
X          tion and to make all targets not depending on targets
X          that could not be made. Ordinarily dmake stops after a
X          command returns a non-zero status, specifying -k causes
X          dmake to ignore the error and continue to make as much
X          as possible.
X
X     -n   Causes dmake to print out what it would have executed,
X          but does not actually execute the commands.  A special
X          check is made for the string "$(MAKE)" inside a recipe
X          line, if found, the line is expanded and invoked,
X          thereby enabling recursive makes to give a full
X          description of all that they will do.  The check for
X          "$(MAKE)" is disabled inside group recipes.
X
X     -p   Print out a version of the digested makefile in human
X          readable form.  (useful for debugging, but cannot be
SHAR_EOF
echo "End of part 15"
echo "File man/dmake.nc is continued in part 16"
echo "16" > s2_seq_.tmp
exit 0